@alexandru Hi, could you check if this makes sense?

@sureshg thanks, but I'm not interested in adding this functionality.

For one, even though the project's aim is to model queues based on RDBMSs, the interface is generic enough that it could use NoSQL, and we can take some liberties with the implementation. For example, it could do sharding, or fallbacks (e.g., from a central RDBMS to a local one in case the central server is offline).

Note, LIMIT $limit OFFSET $offset is a bad way to implement pagination. While in my experience, the tables of a DelayedQueue don't grow large enough, when introducing pagination, one has to assume that they could. And in that case, queries with offset and limit can't be optimized, so I would never do this in a public API. What you can do is to do WHERE id >= ? AND id < ? ORDER BY id, but this involves an API that's more oriented towards streaming (and thus doesn't expose offset, limit, or page as parameters).

Also, being a maintainer for some time, and being friends with other maintainers of popular libraries, I'm wary that the effort required to do drive-by PRs has gone down, this increasing the review burden for maintainers. So I think we need a netiquette to first ask if certain features are desired, before submitting the PR (method signatures in this case would've been enough for me to say no 🙂).

What you can do is to do WHERE id >= ? AND id < ? ORDER BY id, but this involves an API that's more oriented towards streaming

Thanks!

So I think we need a netiquette to first ask if certain features are desired

Sure, totally understand and apologies for that. That was actually my intention too.. I started with the feature request in #24, but then got a bit carried away since the implementation felt small enough to just go ahead with (of course with AI help, especially for Scala part, doc, testing etc). Sorry for the inconvenience!